Symmetric key encryption can provide efficient, secure encryption in cases where keys can be securely exchanged, stored, and maintained, assuming keys are not compromised and plaintext data is sufficiently padded to prevent against attacks (e.g., based upon known plaintext); however, in many cases, secure key exchange itself proves to be difficult where symmetric key encryption, alone, is used.
Asymmetric key encryption provides an alternative to purely-symmetric key encryption, where a public key can be disclosed publicly and even over an insecure medium (susceptible to eavesdroppers), but without compromising plaintext encrypted using the public key, assuming that the corresponding private key remains securely stored and maintained; however, asymmetric key encryption can require more computation and/or more memory when compared to purely-symmetric key encryption, thus suffering from performance issues. Furthermore, if more than one plaintext is encrypted using the same public/private key pair, and the private key is later compromised, all prior communications that had previously been intercepted and recorded are subject to compromise, thus there is no perfect forward secrecy.
A common strategy to accommodate the weaknesses of both purely-symmetric key encryption and purely-asymmetric key encryption is to adopt both symmetric and asymmetric key encryption within a single protocol's encryption method. Secure Socket Layer (SSL) and Transport Layer Security (TLS), for example, as well as technologies built upon them (e.g., HTTPS), utilize asymmetric key encryption for the purpose of performing secure key exchange, where one party in a communication (Alice) generates a random ephemeral session key and securely sends that ephemeral session key to another party (Bob) using Bob's asymmetric public key. In SSL, TLS, and similar technologies, Bob then decrypts the random ephemeral session key using Bob's asymmetric private key, and Alice and Bob encrypt and decrypt plaintext using a mutually-agreeable symmetric key cipher algorithm where the random ephemeral session key is used as the symmetric key. This approach allows for secure key exchange using a relatively inefficient asymmetric cipher, followed by encryption using a more efficient symmetric cipher based on the temporary random key.
SSL and TLS handshaking, where initial key exchange is performed, introduces a lot of overhead in terms of the amount of data transferred. While TLS can be configured to allow sessions to be resumed across multiple connections, these are still prone to timing out and thus requiring a full handshake all over again. As such, across subsequent messages, as well as over longer periods of inactivity or a state of being disconnected, protocols like SSL and TLS (as well as HTTPS) are not efficient due to their repeated need for key agreement via handshaking.
In view of the foregoing, there is a need for improved techniques for exchanging cryptographic information.